As is known, a private branch exchange (PBX) is a telephone system that may be located within an enterprise such as a business, in contrast to telecommunications networks that may be accessed by the general public, such as the public switched telephone network (PSTN) or the Internet. An enterprise utilizing a PBX benefits in a number of ways, one of which is the significant cost savings that result from being able to use a pooled set of trunk lines for calls out to other networks, such as the PSTN, as opposed to having to maintain a trunk line for each telephone extension within the enterprise. Further, users within an enterprise enjoy many valuable features provided by the PBX, such as voice mail, call forwarding, conference calling, etc. Unfortunately, it is generally the case that call management features such as those described above can presently be provided only from within the PBX, thus limiting the ability of users to manage their calls from outside the PBX. Moreover, present systems and methods for accessing call management features in a PBX via an interface external to the PBX suffer from severe disadvantages.
Presently, to enable external access of a PBX for the purpose of providing call management functionality such as that described above, it is necessary to couple a gateway server to the PBX. The gateway server may communicate with the PBX using known telecommunications services such as a Primary-Rate ISDN interface (PRI). The gateway server may in turn communicate with an application server using Session Initiation Protocol (SIP), Voice over Internet Protocol (VoIP), or some other known protocol. SIP is fully discussed in J. Rosenberg et al., RFC 3261, “SIP: Session Initiation Protocol,” June 2002, published by the Internet Society of Reston, Va., presently available on the World Wide Web (e.g., via the faqs.org web site), and fully incorporated herein by reference in its entirety.
Accordingly, it is presently possible to notify an application server of a call in a PBX, and for the application server to send instructions to the PBX regarding how the call should be handled (e.g., forward to voice mail, etc.). However, the afore-described architecture suffers from significant shortcomings. The use of the gateway introduces significant additional overhead into a call routing architecture because the PRI circuits required for communication with the gateway consume significant capacity on the PBX. Further, as should be apparent, this overhead is magnified because each call sent from the PBX to the application server results in a “hairpin” routing of a communication, in which the gateway server is responsible for sending call data to the application server, which then returns data to the PBX through the gateway server. Accordingly, the gateway server used in present architectures represents both a potential bottleneck and a potential single point of failure Thus, present architectures for external call management in a PBX are at best inefficient, and at worst unreliable.
Systems for computer-telephony integration (CTI), not requiring a gateway server as described above, are known for allowing a variety of communications, such as telephone calls, facsimiles, e-mails, and the like to be managed with a computer system. For example, call centers handling large volumes of incoming calls generally use CTI systems to route calls to monitor the availability of service agents, queue calls, and route calls to service agents, etc Similarly, call centers handling outgoing calls often use CTI systems to monitor the availability of telemarketing agents, place outgoing calls, connect telemarketing agents to calls, etc. However, present CTI systems are designed to determine how a call should be answered, i.e., where the call should be sent when it is received, but are incapable of providing a call recipient with the ability to control a call once it has been placed. Moreover, CTI systems use proprietary protocols to facilitate communications between a PBX and the application that makes determinations as to how calls should be routed, such protocols being specifically designed to support the aforementioned functionality provided by most CTI systems.
While it is not at present possible to efficiently and economically provide control of calls in a PBX from without the PBX, such functionality would be highly beneficial to users of the PBX. Most if not all users of telephones connected to a PBX in an enterprise sit in front of a computer connected to one or more networks such as an intranet, the Internet, a local area network (LAN), wide area network (WAN), etc. Further, many users having PBX extensions access computers connected to one or more networks such as the Internet when they are outside of the enterprise, e.g., when at home, at hotels, at branch office locations, etc At present, such users are not typically provided with any interface apart from a conventional telephone through which calls to their PBX extension can be efficiently and effectively managed, and in fact, users of PBX extensions generally have no way at all to determine, on a real time or near real time basis, how a call should be handled. Moreover, to the extent PBX users are presently provided with call management functionality, that functionality is limited to the particular PBX being used.
Accordingly, there is a need to provide call management functionality from outside a PBX to users having PBX extensions. It would be particularly desirable to deploy a system including a proxy utilizing a known protocol or protocols to communicate with an application server providing call management functionality. It would further be desirable for such an application server to accept inputs from a client, and to provide such inputs, specifying how a call should be handled, back to the PBX. Thus, a proxy that provided information to and from a PBX, and to and from an application server, would be a particularly desirable improvement over present systems for managing calls in a PBX.